Method for control of personal data

ABSTRACT

The invention relates to end user controlled handling of personal data on e.g. the Internet. Web services are offered in a controlled manner from a service broker ( 250 ) provided with appropriate security mechanisms. The broker contains end user controlled policies related to personal data/services, while the actual data is arranged at different locations in the network. Web service information is published in an open registry ( 256 ) at the broker. When an application provider ( 220 ) finds a desired service in the registry, its service request is guided to the appropriate service broker. The broker returns the policy for the requested service, whereafter the service provider ( 240 ) can be contacted, preferably through an encapsulated SOAP message. A preferred embodiment performs common sign on authentication when a new application is contacted.

TECHNICAL FIELD

The present invention generally relates to security in communicationsystems and in particular to end user controlled handling of personaldata on the Internet and similar networks.

BACKGROUND

Web service technologies have recently attracted an explosive interestand are sometimes said to be revolutionizing the Internet. A web serviceis basically a network accessible interface to application functionalityimplemented through standard Internet technologies. By means of webservices, one piece of software can access objects and methods fromanother piece of software irrespective of long distances andintermediate firewalls, enabling distributed software systems.

Most web services are packaged in a format based on the ExtensibleMarkup Language (XML) and therefore sometimes referred to as XML webservices. A very common protocol for implementing web services is theSimple Object Access Protocol (SOAP), which is built on XML andtypically carried by the Hypertext Transfer Protocol (HTTP).

It is plain to see that web services hold the potential to increase theavailability of data and services on the Internet, which is not onlyvery advantageous for application developers and data service providersbut would eventually also imply that better application services areoffered to end users. However, using HTTP, XML and SOAP allows anyone toaccess a service that has been published as a web service. This might befine for some content providers like search engines for instance, buttypically a straight “line” to the actual data source is not desirable.In particular, person-related data, such as the content of a positioningsystem, a customer database or a mobile commerce platform, must not behanded out without proper checks.

There are many shortcomings of conventional XML web services, inparticular related to security, privacy and transaction processing. (Seee.g. [1] for a more elaborate discussion on the shortcomings of webservices.) Control of who is allowed to use a particular service, inwhat way the service may be used, etc, are some of the issues that needto be taken care of for web services to become widely spread in thefuture.

To be able to exploit the advantages of web services withoutcompromising the end user integrity would thus be very desirable. Thisobject is addressed in several prior-art solutions, such as standardencryption tools, Private Key Infrastructure (PKI) with signatures andcertificates, etc. These conventional techniques all focus on asituation where the interacting parties know each other, which inparticular for a (mobile) Internet approach is less suitable. Therapidly growing market for web services requires support of “masspartnering”, which implies that new approaches are needed.

Another drawback of conventional web service solutions is that whileaddressing one or a few aspects of web service security, e.g. encryptionor signing, they fail to offer a comprehensive approach consideringaspects like dynamic routing, exchanging digital user identities orenforcing privacy policies. Yet another problem associated with securitysolutions for web services is that they typically require specialadaptations at both ends and therefore are rather complicated toimplement. Moreover, security measures in the prior art arecomparatively cumbersome and time demanding.

Accordingly, the security mechanisms of conventional telecommunicationsystems are far from satisfactory and there is a considerable need foran improved procedure for handling personal data on the Internet.

SUMMARY

A general object of the present invention is to provide an improvedmethod for handling personal data in open networks like the Internet. Aspecific object is to provide a method for offering web services thatinvolve personal data without compromising the security of end users.Another object is to achieve secure web service messaging between two ormore parties. Still another object is to achieve an improved end userauthentication procedure in association with web service requests.

These objects are achieved in accordance with the attached claims.

Briefly, the invention proposes a new way of opening up the Internet ina controlled manner through offering web services from a third partyprovided with appropriate security mechanisms. This third party, theservice broker, contains end user controlled policies related topersonal data/services, while the actual data is maintained at multiplesites in the network. According to the invention, web serviceinformation is published in an open registry at the broker. When forinstance an application provider finds a desired service in theregistry, an application is developed to make use of this service. As anend user attempts to access the application, the application invokes itsweb service gateway that guides the service request to the appropriateservice broker. The location of the service may be unknown to theapplication provider. The broker returns the policy agreement for therequested service, whereafter the service provider can be contacted. Theactual validation of the request can be performed at the broker, at therequesting side or at the providing side.

Although other web service protocols, e.g. another XML web serviceprotocol, can be used in accordance with the invention, thecommunication in the network is preferably based on XML SOAP. Apreferred embodiment uses a new type of messages referred to asencapsulated SOAP messages to achieve reliable three-partycommunication. Furthermore, the invention proposes a new common sign on(CSO) procedure for end user authentication every time a new applicationis contacted. A CSO server is then preferably implemented in the servicebroker and a digital user identity restricted to the service broker isissued. The CSO server may communicate with a policy repository of theservice broker to improve the system performance.

According to other aspects of the invention a communication system and adevice for end user controlled handling of personal data are provided.

BRIEF DESCRIPTION OF THE DRAWINGS

The invention, together with further objects and advantages thereof, isbest understood by reference to the following description and theaccompanying drawings, in which:

FIG. 1 is a schematic view of a prior art communication system for enduser control of personal data;

FIG. 2 is a schematic view of a communication system for end usercontrolled handling of personal data according to an exemplaryembodiment of the present invention;

FIG. 3A illustrates messaging through encapsulated SOAP messagesaccording to a first exemplary embodiment of the present invention;

FIG. 3B illustrates messaging through encapsulated SOAP messagesaccording to a second exemplary embodiment of the present invention;

FIG. 4 illustrates messaging through encapsulated SOAP messagesaccording to a third exemplary embodiment of the present invention; and

FIG. 5 is a flow chart of a method for end user controlled handling ofpersonal data according to a preferred embodiment of the presentinvention.

DETAILED DESCRIPTION

As outlined in the background section, conventional XML web services areassociated with many shortcomings related to security and privacy. Thepresent invention is based on the recognition that these can be overcomeby a communication system that is based on the system disclosed in [2](hereafter referred to as “the classic Lock Box”) but which is adaptedto web services and provided with additional advantageous functionalityin a way that will be described in the following.

One implementation of the classic Lock Box is shown in FIG. 1, which isa schematic view of such a prior art communication system for end usercontrol of personal data. The illustrated system 100 includes arequesting application 122 with access means 124, an informationproviding application 146 with access means 142, central server means150 comprising a central server 152 and an associated database (DB) 154,and an information holding database 148. Each access means 124, 142 alsohas a respective database 126, 144. The access means are arranged tocommunicate with the central server means, which handles informationrouting and personal profile locking/unlocking using personal protectionprofiles stored in the database 154.

Upon being contacted by an end user 110, the requesting application 122typically sends a request for personal profile data located anywhere inthe network to the access means 124 for the purpose of either fetchingdata or setting new data in the personal profile. The access means 124invokes its database 126 to find out the address of the central servermeans 150 to which the request should be forwarded. Via secure HTTP(HTTPS), the request is forwarded to the central server 152 whichestablishes, using the personal protection profiles in database 154,whether the access request should be allowed or not. An indication ofrejection or grant is returned to access means 124, which in case ofgrant uses HTTPS for communication with access means 142 over theInternet 130. Access means 142 contacts the providing application 146,which retrieves the data from the information holding database 148. Theinformation is returned to the requesting application via access means142, over the Internet 130 and access means 124.

A main feature of the classic Lock Box system 100 is that access rightsto personal information are administered by the end user 110 at acentral location (the central server means 150), whereas the personalprofile data, i.e. the information as such, is distributed throughoutthe communication system on different sources 148. The end user is thusprovided with a central facility where he can lock/unlock, i.e.customize access to, personal information from different providers andto different information requesters.

Moreover, by means of the classic Lock Box the identities of therequesting side can be concealed for the providing side and vice versa.There is no connection between personal information from differentlocations without going through the user controlled central server means150. By spreading out the personal profile data at different locations(or at the same location but unrelated) with different user identities,a high degree of end user privacy is obtained.

The messaging in the classic Lock Box system uses XML text. Hereby, anew type of XML forms, which is described in [3], can for example beused. Each information service needs a DTD agreement that defines theallowed flow of data between the concerned communication pair(requesting and providing application). This means that a new XML formhas to be created and implemented at the application side every time anew service is provided.

For further details on the Lock Box concept, reference is made to [2].

FIG. 2 is a schematic view of a communication system for end usercontrolled handling of personal data according to an exemplaryembodiment of the present invention. A communication system 200comprising an application unit 220, a data providing unit 240 and aservice broker 250 is shown. End users communicating with theapplication unit 220 are in the figure represented by a cellular phone210-1, a personal computer (PC) 210-2 and a laptop 210-3. The cellularphone 210-1 typically uses an intermediate device, such as a WirelessApplication Protocol (WAP) gateway, to contact the application unit. Theapplication unit 220 comprises an application node 222 and an accessmeans 224, e.g. a web service gateway. The access means 224 cancommunicate with access means 242 of the data providing unit 240 inorder to get (or set) personal data, e.g. biometrics or position data,contained in information holding means 248, such as a database (DB).Between the access means 242 and the database 248 of the data providingunit 240, there is optionally a web service interface logic node 245.Both the application unit 220 and the data providing unit 240 has meansfor communicating with the service broker 250, which in the illustratedexample includes a CSO server 255, a Universal Description, Discoveryand Integration (UDDI) server 256, a Web Service Definition Language(WSDL) server 258, and a web service policy repository 252 with anassociated database 254.

The communication between the nodes in FIG. 2 is based on a predefinedweb service protocol, such as a predefined XML web service protocol.Preferably, the messages are exchanged through SOAP over HTTPS but anyappropriate web service protocol could be used for packaging messageswithin the scope of the invention, including other XML-based protocolsas well as SOAP based on another transport protocol than HTTP. Whenusing SOAP for service requests, the variables can have an associatedvariable type (e.g. integer or string), which is advantageous from aprogramming point-of-view.

The major flows of sequences in the system are in FIG. 2 indicated byarrows I-IX. In an initial set-up procedure the data providing unit 240communicates a data service to the service broker 250 (I), where it ispublished in the UDDI server 256. (In practice, this phase wouldgenerally include several providers and several services.) An end user210 that would like to request a published service (and get or set data)contacts the application node 222 with a request message (II). Therequest is preferably based on SOAP and accompanied by out of band (OOB)data, i.e. non-payload/control information, which will be furtherdescribed with reference to FIG. 4A. Preferably, a CSO server 255 isinvoked from the application node 222 for user authentication purposes(III). In case of a successful authentication, the request istransferred via the access means 224, where it is subject to certainprocessing, and delivered to the policy repository 252 of the servicebroker 250 (IV, V). Preferably, the access means 224 comprises alist/database telling where to find the appropriate service broker. Thepolicy repository 252 matches the requested service with the appropriatepolicy, which is fetched from the database 254 (VI). At this stage,there is generally a user identity change at the service broker in orderto conceal the original user identity for the access means 242 of thedata providing unit 240 and to help the providing unit 240 identify theend user 210. The policy is preferably returned to the access means 224together with a response message containing the new user identity (V).

The request validation is performed by the policy repository 252, theaccess means 224 or the access means 242. In case of a successfulrequest (or in case the validation is to be performed at the accessmeans 242), the data providing unit 240 is contacted (VII), preferablythrough an encapsulated SOAP message. Its access means 242 dissemblesthe encapsulated SOAP message such that only the original request fromthe application node 222 reaches the web service interface logicstructure 245 (VIII). This node is optional and mainly serves toterminate SOAP if the information holding means/data source 248 does notsupport web services. The requested service/data is finally collected atthe data source 248 IX and returned to the application node 222 and theend user 210 (IX, VIII, VII, IV, II).

Preferably, all links of a communication system according to theinvention are protected by means of encryption. For this, standardencryption methods can with advantage be used.

The nodes of a network according to the invention can connect to eachother in several ways. One possibility is that the application node 222and the data source 248 are web or WAP applications in a server toserver scenario where the nodes 222, 224 of the application unit as wellas the nodes 242, 245, 248 of the data providing unit run from Internetor intranet servers. In a second case the application unit nodes 222,224 reside in a client, e.g. a PC, a personal digital assistant (PDA) oran advanced cellular phone, while the providing unit nodes 242, 245, 248run from servers. The application node 222 can for example be a Windowsclient application and the functions in the access means 224 part of anoperating system or a program running in the background. A third exampleis peer-to-peer communication, where the nodes of both sides run onclients for data sharing without a central data repository.

It should be noted that a communication system in accordance with theinvention generally would comprise a more complex network than the basicexample of FIG. 2. Such a system includes multiple application units,data providing units and/or service brokers that are able to communicatewith each other. Furthermore, it is to be understood that all nodesbelonging to the same unit in FIG. 2 not necessarily have to be arrangedat the same physical location. The databases 248, 254, respectively, mayfor example be located at another physical device than the nodes 242,252, respectively.

The invention thus uses a structure based on the classic Lock Box toprovide web services in a secure manner. The web services are publishedat the service broker through a new procedure for brokered publishing.The communication is mainly SOAP based and a new type of SOAP messages,so called encapsulated SOAP messages is used to achieve a securethree-part communication. Brokered web service publishing andencapsulated SOAP messages are closely linked features necessary for theinvention. A common sign on mechanism is preferably also provided, whichhandles user identities and interacts with the mentioned features tofurther improve the system security and performance. The respectivemechanisms for brokered publishing, common sign on and encapsulated SOAPmessages will now be described more thoroughly.

Brokered Publishing

Still referring to FIG. 2, a fundamental feature of the presentinvention is the web service publishing that is performed at the servicebroker 250. Assume that a content provider would like to offer aservice, typically involving person-related data in its associated datasource 248, via a web service interface. A web service description isthen transferred from the providing unit 240 to the service broker 250(I). The web service description preferably comprises a WSDL file withinformation about how to invoke the service but may also includeadditional information parameters, such as the price for using theservice, periods of validity for the service and price, a contactaddress for the service, etc. The WSDL file is stored at the WSDL server258 of the service broker.

The broker registers information about the web service at the UDDIserver 256, whereby it becomes published in a look up register togetherwith a number of other services. The web service information publishedin the UDDI registry generally includes an identity for the service andthe address (e.g. the Uniform Resource Locator, URL) of the serviceprovider. The web service information for each web service in the UDDIis linked to the respective WSDL file. Thereby, any applicationprovider/developer can access the UDDI registry in search for servicedata to be used in a new application and download the web servicedescription of appropriate services.

Upon receiving a web service description from the data providing unit240, the service broker 250 suggests a policy for privacy andinformation element control to the providing unit. After a successfulhandshaking procedure, the broker adds the agreed policy into the policyrepository 252, which stores it in its database 254. The policypreferably comprises a DTD or XML schema agreement. The policy is atthis stage generic and does not relate to a particular end user.However, later on user-specific policies can be created.

When a number of services have been assigned respective policies andpublished at the service broker, it is thus possible for an end user toadapt these policies by defining his own rules concerning to whichrequesters the personal data is to be available. This could be done bycontacting the service broker, e.g. via the Internet or a WAP enabledphone. Alternatively, if the end user has not personalized the policyfor a service in advance, he can be invited to do so upon requesting theservice.

Preferably, the system of the invention uses further securitymechanisms, e.g. corresponding to those described in [2], to achievesecure web service publishing. The access means of the application unitis for example preferably assigned an identity by the service broker.

By means of the invention, it is possible to publish a web servicewithout having to worry about who is requesting the service. The servicebroker ensures that a high degree of security and privacy is preserved.Moreover, the invention likewise enables requesting a web servicewithout having to worry about who is responding. This means that checksin order to make sure that the service is requested from a reliableparty are no longer needed, since the service broker is a trusted party.

Another major advantage of the web service handling according to theinvention is that it can be performed in an automated manner requiring aminimum of implementing actions at the application unit. This is due tothe fact that the invention allows use of standard tools and methods forweb service development, such as the WSDL and UDDI servers. With thisweb service automation there is for example no need for the requestingapplication to “hunt down” the structure for XML forms that have to bemanipulated to suit each case.

Furthermore, the brokered publishing of the invention enables fastprocedures for both uploading and finding web services. New applicationscan be built in a comparatively simple and fast manner and the overallsystem performance is hence speeded up.

The present invention considerably increases the availability of themobile Internet. Today, application developers/application serviceproviders experience a number of difficulties in accessing the servicelayers and data sources of one or several operators. Specific agreementswith several involved operators are often required and different accesstypes have to be handled. The market is restrained since a lot of time,money and effort is spent on negotiations with operators and ondeveloping access techniques. This is avoided by means of the proposedservice broker solution, according to which the support is the same fordifferent sources of information. Small companies can open mobileInternet sites and automatically collect money, without having to worryabout building a user registry of their own or negotiating about accessto the service layers of one or several operators. Thus, the inventionallows developers of mobile applications to concentrate on their keyissue.

Common Sign On

A preferred embodiment of the invention handles authentication throughthe new common sign on (CSO) concept. In such a case, redirection occursfrom the application node 222 to a CSO server 255, to which a set ofcredentials, such as a user name and a password, is input. Thecredentials are requested every time a new application is accessed bythe user. The CSO server creates a general digital user identity forauthentication, which is encrypted such that it can only be read by theservice broker 250.

The fact that the digital user identity is only valid in the servicebroker domain 250 implies that the protected user identity returned tothe application node 222 cannot even be read by the application nodeitself. This results in enhanced security and at the same time allowsfor a new kind of application service provider that is principallyinterested in selling its application/service and does not care aboutcustomer identities. Still, CSO does not in any way exclude traditionalapplication service providers with customer databases.

As illustrated in FIG. 2, the CSO server 255 is preferably arrangedwithin the service broker 250 to communicate with the policy repository252. Thereby, the CSO server can alert the policy repository of anexpected request at an early stage. By forwarding the user and serviceidentities to the policy repository, the policy repository is given theopportunity to contact its database 254 and prepare for the request byretrieving the associated policy. In this way, there is a fast responsewhen the actual request is received, resulting in the further improvedperformance of a real time system.

It is preferred that an identity of the CSO node is transferred via theapplication node (A) and the access means (B) to the policy repository(C) in case of a successful authentication. Together with thepreparation initiating message sent from the CSO service to the policyrepository, this provides the policy repository with appropriateinformation for interpreting the session identity.

CSO only requires one set of credentials for all applications connectedto the network. In this respect, the CSO authentication of the inventionis similar to conventional single sign on (SSO) mechanisms, e.g.Microsoft Passport™. However, whereas SSO only requires credentials tobe given once for each respective session, CSO requires credentials tobe given every time a new application is accessed. This means that therisk of abuse is reduced. If the device is stolen during an opensecurity session, abuse is limited to this particular application.

In a favorable scenario, the CSO server 255 is run and managed by amobile operator, which means that the operator provides the digitalidentities. The circle of trust is thereby extended by the invention inthe sense that enablers (e.g. mobile positioning centers, multimediamessaging service centers, charging nodes or other nodes in theoperator's service layer) can trust the identities. Moreover, bymanaging digital identities via a CSO server, the operators are close tothe end users and can safeguard their positions.

There may be embodiments where the CSO server is connected to otheridentity providers, including Microsoft Passport™ or products compliantto Liberty Alliance specifications. This simplifies the end usermanagement, since the same credentials can be used in the CSO aselsewhere.

To sum up, through CSO the invention offers a safe authenticationmechanism that does not rely on trusting external parties and by meansof which the risk of abuse is reduced. CSO also results in an improvedperformance of the policy repository.

Encapsulated SOAP Messages

FIG. 3A illustrates messaging through encapsulated SOAP messagesaccording to a first exemplary embodiment of the invention. Theparticipating units are the application node (A) 322 of the applicationunit, the gateway/access means (B) 324 of the application unit, theservice broker (C) 350 and the gateway/access means (D) 342 of the dataproviding unit. The application node A wants to retrieve information orrequest a service involving personal data, the location of which it doesnot know. In the first messaging stage, A uses SOAP to invoke accessmeans B, typically over an intranet or within the same node. The message360 sent from A to B comprises a conventional SOAP envelope with aheader and a body. The header contains OOB data, such as for example asignature from A, a time stamp and identities for the requestedservice/data, the node A, the end user and/or the person performing therequest. The body, on the other hand, contains a payload message withthe actual request. The request is typically implemented through astandard XML form.

In the next stage, B creates an encapsulated SOAP message 370, which issent to the policy repository (252 in FIG. 2), of the service broker C.Hereby, SOAP based on HTTPS would generally be used. The original SOAPmessage 360 from A is encapsulated in the body of the message 370. Badds its own identity, possibly together with OOB data corresponding tothe above-mentioned example OOB from A and other OOB data (e.g. relatedto the maximum service cost), to the SOAP body. Preferably, the headerof the message 370 only contains a signature provided by B, in whichcase the entire body is protected from manipulation.

When the policy repository of C receives the message with theencapsulated A request from B, it retrieves the appropriate policy fromits associated database (254 of FIG. 2). This policy is returned to unitB in a new encapsulated SOAP message 380 signed by C. Besides thepolicy, the message body preferably contains additional OOB data from Cas well as the previous message 370. This additional OOB data can forinstance include an identity of C, the IP address of D, the useridentity in D (issued by C) and information about where validation is totake place and how long the policy is valid (a best-before time stamp),etc.

Unit B finally encapsulates the message 380 received from C (preferablyafter performing a “best before time” check thereof) into another SOAPmessage 390 and transmits this message to the access means D of the dataproviding unit. In the illustrated example, all components of themessage 390 are already signed at other units participating in themessaging scheme, as well as provided with a best-before time stamp fromC 350, and therefore yet another signing by B would be superfluous.However, it is preferred to include a session identity in the header ofthe message 390, whereby parameters can be related to a specific sessionand thus saved during the session for restoration purposes.

More information about the OOB data added by the units A, B and C,respectively, can be found in [2].

FIG. 3B illustrates messaging through encapsulated SOAP messagesaccording to a second exemplary embodiment of the invention. Themessaging in FIG. 3B resembles the one in FIG. 3A in that a new SOAPmessage 470, 480, 490 is built in each stage by encapsulating theprevious SOAP message 460, 470, 480. Furthermore, the components of themessages are basically the same. However, while everything except thecurrent signature was arranged in the body of the SOAP message in FIG.3A, new components are instead added to the header of the respectivemessages 470, 480, 490 in FIG. 3B. Hence, the bodies of the messagesmerely contain the original payload message from A. A consequence ofthis is that, to achieve maximum security, it can in some cases beappropriate to let access means B 424 sign the message 490 destined foraccess means D 442, as in the illustrated example. However, this signingevent can also be left out, for example if the gained security is notconsidered to outweigh the system effort associated with the signing.

FIGS. 3A and 3B illustrate two different approaches as for whether theadded data is arranged in the header or body of the encapsulated SOAPmessages. The preferred way is to put everything except the most recentsignature in the SOAP body to obtain a maximum security. However, asillustrated by FIG. 3B, it is also possible to instead arrange at leastpart of the added data in the SOAP header. Such an approach results in afaster signing procedure and may be appropriate in situations where theparticipating parties trust each other. Decisions related to if and towhat extent data can be placed in the SOAP header instead of in the bodyinvolve a compromise between security and performance.

The solutions of FIGS. 3A and 3B offer a centralized messaging schemewhere the entire message from A is passed on to the service broker C.The request is visible to C, which can compare the request against theassociated policy in its database to check whether the request isallowed or not. In a preferred embodiment, C performs such a validationof the request and thereafter sends an explicit indication of the resultto B. If the request is allowable, an indication thereof is included inthe OOB of message 380, 480 and the messaging scheme is continued withthe message 390, 490 to D as in FIGS. 3A and 3B. However, should Cencounter an illegitimate request, an indication telling that access isdenied is instead included in the OOB returned to B, whereafter themessaging procedure is interrupted. An attempt by a malicious/hacked Bto still contact D with the encapsulated SOAP message will fail, since Drejects it upon seeing the indication signed by C.

The above-described solution where C checks the request has theadvantage that it results in an early validation where B quicklyreceives a notice of whether the request will succeed or not. However,the invention also covers embodiments where C just forwards theretrieved policy together with the request and the validation isperformed at a later stage, for instance at unit B or D.

FIG. 4 illustrates messaging through encapsulated SOAP messagesaccording to a third exemplary embodiment of the invention. In thisapproach, the access means B 524 of the application unit has a crucialrole. The first stage, where A 522 requests a service by sending a SOAPmessage 560 to B, is the same as before. Thereafter, B reads the requestand determines which information therein that should be passed on tounit C 550. This information generally comprises the identity of therequested service, which is placed in the body of a SOAP message 570signed by B and sent to C. Thus, C is not provided with all detailsconcerning the request but merely a minimum of information needed forretrieving the appropriate policy. This messaging scheme is totallydifferent from the above cases where B incorporated the entire XML formwith the payload message in the new SOAP message for C irrespective ofits content.

The policy repository of C collects the policy that matches the serviceidentity from its associated database and creates a SOAP message 580with OOB including the policy in the body and a signature by C in theheader. The message 580 is sent to B, which encapsulates it in the SOAPmessage 560 from A, forming a message 590 sent to D 542. Equivalently,the message 560 can be incorporated in the message 580. In either case,the encapsulated SOAP message 590 preferably contains a header with asignature by B for a body comprising the content of messages 560 and580.

In the messaging scheme illustrated in FIG. 4, the service broker C 550generally does not have enough information to decide whether the requestis allowed. This decision therefore has to be made at a later stage,e.g. at B 524 and/or at the data providing side, to which units theoriginal A request and the policy from C are both available. It wouldgenerally be preferred to validate the request at D 542.

The encapsulated SOAP messaging schemes of FIGS. 3A, 3B on the one handand 4 on the other hand each have their pros and cons and the choice ofmessaging procedure is basically determined by the degree of trust putin the access means 324, 424, 524 of the application unit. If thisaccess means is considered less trustworthy, it may be appropriate touse the scheme of FIG. 3A, which is very secure. Then, a centralizedsolution is achieved since the service broker 350 sees the request andcan check whether it is allowed or not. This means that the servicebroker can refuse to forward a non-admissible request. The drawback ofsuch a centralized solution is that all information from A 322,including the XML request form, goes through the service broker, whichbecomes the “bottleneck” of the system. From a load-optimizingpoint-of-view it is therefore preferred to use the scheme of FIG. 4 ifthe access means on the application side is trusted.

It should be emphasized that the messaging procedure described withreference to FIGS. 3A, 3B is not excluding the one described withreference to FIG. 4 and vice versa. In fact, a preferred embodiment ofthe invention employs both methods running in parallel. The choice ofmessaging procedure for a particular situation is then determined bytrust and performance considerations, above all the degree of trust putin the access means of the application unit.

In the described messaging schemes, the service broker is for requestvalidation purposes invoked from the application unit. Sometimes it canbe appropriate to invoke the service broker from the providing unit aswell, for example if the provider has doubts about the authority of therequester. Such cases also lie within the scope of the invention.

FIG. 5 is a flow chart summarizing a preferred method for end usercontrolled handling of personal data according to the invention. Theprocedure starts with offering web services at the broker. A web servicedescription comprising a WSDL file is transferred from the data providerthat controls the data/service to the service broker in a step S1. Theservice broker suggests a privacy policy for the service and in a stepS2 web service information with a pointer to the web service descriptionis published at the UDDI registry of the service broker. The steps S1and S2 are generally repeated, filling the web service registry with anumber of services offered by several different providers. Anapplication developer/provider can thereafter search the open webservice registry in order to provide end users with services compliantwith their needs. The respective service policies may either bepersonalized by the user in advance or upon requesting a service.

The pull/push procedure starting when an application node requests aparticular service is outlined in steps S3-S9. User authentication ispreferably performed at a CSO server in the broker upon each applicationrequest (step S3). Hereby, the CSO server uses a digital user identityonly valid in the service broker. Step S4 asks whether theauthentication was successful. If not, the procedure ends in step S5. Incase of a successful authentication, on the other hand, the servicerequest is communicated from the application node to the service brokervia the access means/gateway of the application unit (step S6). Theservice broker matches the service identity with a user defined policy(privacy agreement) that is returned to the access means of theapplication unit is step S7. In step S8, this access means preferablycreates an encapsulated SOAP message in order to transfer the servicerequest from the application node and the policy from the policyrepository in a reliable manner. The encapsulated SOAP message istransmitted to the data providing unit in step S9, which retrieves therequested data from its database, possibly after checking the requestagainst the associated policy.

The present invention is especially useful for providing web servicesinvolving personal data. However, it can also be used for general webservices not requiring any person-specific information. The servicebroker can for instance use a fictitious end user and password forhandling such services.

Although the invention has been described with reference to specificillustrated embodiments, it should be emphasized that it also coversequivalents to the disclosed features, as well as modifications andvariants obvious to a man skilled in the art. For instance, informationelements of the SOAP messages can in all cases be moved from body toheader, and vice versa. Thus, the scope of the invention is only limitedby the enclosed claims.

REFERENCES

-   [1] “Web Service Gotchas—How enterprises can build secure reliable    performance-optimized service solutions while waiting for the    standards to mature”, Bloor Research NA, July 2002.-   [2] U.S. patent application Ser. No. 09/976,500 (Pub. No.    2003/0074456 A1), Ericsson Inc.-   [3] U.S. patent application Ser. No. 09/994,339, Ericsson Inc.

1. A method for end user controlled handling of personal data in acommunication system including an application unit with a first accessmeans arranged to communicate with a data providing unit and a servicebroker comprising the steps of transmitting a description of a webservice from the data providing unit to the service broker; publishing,at the service broker, web service information associated with the webservice description; communicating, based on a predefined web serviceprotocol, a service request from an application node of the applicationunit to the service broker via the first access means; and returning,based on the predefined web service protocol, an end user controlledprivacy agreement for the requested service from the service broker tothe application unit.
 2. The method of claim 1, wherein the predefinedweb service protocol is a predefined Extensible Markup Language (XML)web service protocol.
 3. The method of claim 2, wherein the predefinedXML web service protocol is the Simple Object Access Protocol (SOAP). 4.The method of claim 3, further comprising the steps of: creating, at thefirst access means an encapsulated SOAP message based on the servicerequest and the privacy agreement; and transmitting the encapsulatedSOAP message from the first access means to a second access of the dataproviding unit.
 5. The method of claim 4, further comprising the stepsof: receiving, at the first access means, a SOAP request message fromthe application node; communicating a first intermediate encapsulatedSOAP message including the SOAP request message from the first accessmeans to the service broker communicating a second intermediateencapsulated SOAP message including the first intermediate encapsulatedSOAP message and the privacy agreement from the service broker to thefirst access means; and forming the encapsulated SOAP message for thedata providing unit by incorporating the second intermediateencapsulated SOAP message.
 6. The method of claim 5, comprising thesteps of: arranging substantially all content of the encapsulated SOAPmessages in a SOAP body thereof; and signing the first and secondintermediate encapsulated SOAP messages respectively, at the firstaccess means and the service broker respectively.
 7. The method of claim5, comprising the steps of: arranging substantially all content exceptthe service request of the encapsulated SOAP messages in a SOAP headerthereof; and signing the respective encapsulated SOAP message.
 8. Themethod of claim 4, wherein the creating step in turn comprises:encapsulating the content of a first SOAP message in a second SOAPmessage whereby one of the messages comprises the service request fromthe application node and the other message comprises the privacyagreement from the service broker; and signing the second SOAP message.9. The method of claim 1, further comprising the step of performing, ata common sign on (CSO) server, an end user authentication event forevery application request received at the application node.
 10. Themethod of claim 9, wherein the CSO server is arranged in the servicebroker to communicate with a policy repository unit thereof.
 11. Themethod of claim 9, wherein the end user authentication event involves auser identity, the validity of which substantially is restricted to theservice broker.
 12. The method of claim 1, wherein the privacy agreementis selected from the group of a Document TypeDefinition (DTD) agreementand an XML schema agreement stored in the service broker.
 13. The methodof claim 1, wherein the web service description comprises a Web ServiceDefinition Language(WSDL) file and the publishing step is performed at aUniversal Description, Discovery and Integration (UDDI) server of theservice broker.
 14. A communication system for end user controlledhandling of personal data including an application unit with a firstaccess means arranged to communicate with a data providing unit and aservice broker, said system comprising: means for transmitting adescription of a web service from the data providing unit to the servicebroker; means for publishing, at the service broker, web serviceinformation associated with the web service description; means forcommunicating, based on a predefined web service protocol, a servicerequest from an application node of the application unit to the servicebroker via the first access means; and means for returning, based on thepredefined web service protocol, an end user controlled privacyagreement for the requested service from the service broker to theapplication unit.
 15. The system of claim 14, wherein the predefined webservice protocol is a predefined XML web service protocol.
 16. Thesystem of claim 15, wherein the predefined XML web service protocol isSOAP.
 17. The system of claim 16, further comprising means for creating,at the first access means, an encapsulated SOAP message based on theservice request and the privacy agreement; and means for transmittingthe encapsulated SOAP message from the first access means to a secondaccess means of the data providing unit.
 18. The system of claim 17,further comprising: means for receiving, at the first access means, aSOAP request message from the application node; means for communicatinga first intermediate encapsulated SOAP message including the SOAPrequest message from the first access means to the service broker; meansfor communicating a second intermediate encapsulated SOAP messageincluding the first intermediate encapsulated SOAP message and theprivacy agreement from the service broker to the first access means; andmeans for forming the encapsulated SOAP message for the data providingunit by incorporating the second intermediate encapsulated SOAP message.19. The system of claim 18, wherein the content of the first and secondintermediate encapsulated SOAP messages, respectively, are signed by thefirst access means and the service broker, respectively.
 20. The systemof claim 17, wherein the means for creating in turn comprises: means forencapsulating the content of a first SOAP message in a second SOAPmessage, whereby one of the messages comprises the service request fromthe application node and the other comprises the privacy agreement fromthe service broker; and means for signing the second SOAP message. 21.The system of claim 14, further comprising a CSO server for performingan end user authentication event every time an application requestreaches the application node.
 22. The system of claim 21, wherein theCSO server is arranged in the service broker to communicate with apolicy repository unit thereof.
 23. The system of claim 21, wherein theend user authentication event involves a user identity, the validity ofwhich substantially is restricted to the service broker.
 24. The systemof claim 14, wherein the privacy agreement is selected from the group ofa DTD agreement and an XML schema agreement stored in the servicebroker.
 25. The system of claim 14, wherein the service broker comprisesa WSDL server for storing a WSDL file of the web service description anda UDDI registry for the web service information.
 26. An intermediatedevice belonging to an application unit in a communication system forend user controlled handling of personal data, adapted to communicatewith a data providing Linit and a service broker of the communicationsystem and comprising: means for receiving a SOAP request message with aservice request from an application node of the application unit; meansfor communicating the service request to the service broker using SOAP;means for receiving, from the service broker, a privacy agreementcorresponding to the service request; means for creating an encapsulatedSOAP message based on the SOAP request message and the privacyagreement; and means for transmitting the encapsulated SOAP message tothe data providing unit.
 27. The device of claim 26, further comprising:means for communicating a first intermediate encapsulated SOAP messageincluding the SOAP request message to the service broker; means forreceiving a second intermediate encapsulated SOAP message including thefirst intermediate encapsulated SOAP message and the privacy agreementfrom the service broker; and means for forming the encapsulated SOAPmessage for the data providing unit by incorporating the secondintermediate encapsulated SOAP message.
 28. The device of claim 27,comprising means for signing encapsulated SOAP messages.
 29. The deviceof claim 26, wherein the means for creating in turn comprises: means forencapsulating the content of a first SOAP message in a second SOAPmessage, whereby one of the messages is the SOAP request message fromthe application node and the other comprises the privacy agreement fromthe service broker; and means for signing the second SOAP message. 30.The device of claim 26, comprising means for encrypting encapsulatedSOAP messages.
 31. The device of claim 26, comprising means forcomparing the SOAP request message against the privacy agreement forauthentication purposes.